A principal aim in the debug process is to non-intrusively capture the activity of a microprocessor execution unit embedded in a device under test (DUT). Firmware development and debugging of the embedded microprocessor requires access to the firmware stored typically in a random access memory (RAM). The final code is then committed to a memory. Typically a read only memory (ROM) is used in embedded devices because ROM by nature is not changeable or editable, it takes up a smaller area than RAM, therefore it is quite common for embedded device to commit the firmware code to ROM once system testing has completed. To achieve a firmware debugging, a microprocessor must be controlled and observed via its external connections. However, access to a microprocessor that is deeply embedded within a DUT can only be achieved via the external pins of the densely packaged and typically high speed embedded device. Therefore embedded devices have made the traditional in-circuit emulator (ICE) ineffectual owing to the inaccessibility of the embedded microprocessor.
Moreover, since the code in the ROM cannot be altered, typically an image of the ROM is created in the RAM of the microprocessor by a debugger program and the image is used to perform firmware debugging. However, many embedded devices do not have adequate RAM space for storing the entire image of their ROM code.
Software break points (SWBP) provide another mechanism to allow the debugging of microprocessor code and to evaluate performance. A SWBP is typically accomplished through code replacement, provided the program resides in a writable memory module (e.g., a RAM) which allows the code at the stop point to be replaced in memory with the software break point code. In most devices, when a SWBP code reaches an instruction execution, it causes the application program to stop advancing and sets a debug status bit indicating the application program has stopped. To restart execution, the application program can be restarted by simply refetching the code at the SWBP memory address after the code is replaced in memory with the original code.
However, firmware debugging of a wireless device in its final form is challenging due to lack of observability into the execution of the firmware code stored in a ROM of the wireless device. For example, to debug a Bluetooth device such as a Bluetooth keyboard or mouse, the serial port of the processor will have to be brought out to a typically nine-pin connector (e.g., a serial port, such as a universal asynchronous receiver transmitter (UART) connector) through which a serial port cable can then connect to a personal computer (PC) host which runs the debugger program. The debugger program then passes various commands to a small monitor program that resides in the embedded device to facilitate the controlled execution of the target firmware.
Thus, conventional methods for firmware debugging of a wireless device is intrusive and potentially destructive. Furthermore a test jig and/or opening of the DUT is needed to provide a debug interface to probe the execution of the firmware. The conventional methods also need to have large external RAM space to allow “von Neumann” structure. This means that access is possible from data and code space to the RAM.
Therefore, there is a need to a firmware debugging method and system for wireless devices that enables an efficient debugging of the DUT, without the need for opening of the DUT.